Afile server is a computer that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer may be embodied as a storage system including a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a speciallyformatted file in which information about other files and directories are stored.
A filer may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the filer by issuing file system protocol messages, usually in the form of packets, to the filer over the network.
As used herein, the term storage operating system generally refers to the computer-executable code operable on a storage system that manages data access and client access requests and may implement file system semantics in implementations involving filers. In this sense, the Data ONTAP™ storage operating system, available from Network Appliance, Inc. of Sunnyvale, Calif., which implements a Write Anywhere File Layout (WAFL™) file system, is an example of such a storage operating system implemented as a microkernel within an overall protocol stack and associated disk storage. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
The disk storage is typically implemented as one or more storage volumes that comprise physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof, volume and file system shall generally be used synonymously. The disks within a volume are typically organized as one or more groups of Redundant Array of Independent Disks (RAID). RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate storing of parity information with respect to the striped data. As described herein, a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity partitions in a single disk) arranged according to a RAID 4, or equivalent high-reliability, implementation.
Additionally, a filer may be made more reliable and stable in the event of a system shutdown or other unforeseen problem by employing a backup memory consisting of a non-volatile random access memory (NVRAM) as part of its architecture. An NVRAM is typically a large-volume solid-state memory array (RAM) having either a back-up battery, or other built-in last-state-retention capabilities (e.g. a FLASH memory), that holds the last state of the memory in the event of any power loss to the array.
Packets of information are received at a filer by a network subsystem comprising one or more integrated software layers that provide data paths through which clients access information stored in the filer. The received information is typically copied into memory buffer data structures or mbufs in the filer's “in-core” memory. The mbufs organize the received information in a standardized format that can be manipulated within the network subsystem. For instance, each mbuf typically comprises header and data portions of a predetermined size and format. Information stored in an mbuf may include a variety of different data types including, inter alia, source and destination addresses, socket options, user data and file access requests. Further, an mbuf also may reference information contained in a separate mbuf data section. Mbufs can be used as elements of larger data structures, e.g. linked lists, and are particularly useful in dynamically changing data structures since they can be created or removed “on the fly.” A general description of mbuf data structures is provided in TCP/IP Illustrated, Volume 2 by Wright et al (1995) which is incorporated herein by reference.
A filer often receives information from a network as data packets of various lengths. Accordingly, these packets are received by the filer's network subsystem and are copied into variable length “chains” (e.g., linked lists) of mbufs. However, the filer's storage subsystem (e.g., including its file system) usually operates on fixed-sized blocks of data. For instance, the WAFL file system is configured to operate on data stored in contiguous 4 kilobyte (kB) blocks. Therefore, data received by the filer must be converted from the variable length mbufs used within the filer's network subsystem to fixed-sized data blocks that may be manipulated within its storage subsystem.
Conventionally, the process of converting data stored in mbufs to fixed-sized blocks involves copying the contents of the mbufs into one or more fixed-sized data buffers in the filer's memory. While the network subsystem maintains “ownership” (i.e., control) of the mbuf data structures, the fixed-sized data buffers instead are managed within the storage subsystem. After the mbufs' data has been copied into the fixed-sized data buffers, the network subsystem typically de-allocates the mbufs. More specifically, the de-allocated (“free”) mbufs may be placed in a list or “pool” of free mbufs that later may be used to store new data packets received at the filer.
Problems often arise because a significant amount of time and system resources, such as memory and central processing unit (CPU) cycles, is typically required to copy received data from variable length mbufs to fixed-sized data buffers. Moreover, the consumption of time and resources becomes particularly noticeable when the contents of a large number of mbufs must be copied to fixed-sized data buffers before their contained data may be written to disk storage. It would therefore be desirable to minimize the number of times received data is copied from mbuf data structures into fixed-sized data buffers, e.g., in the process of writing the received data to disk storage.